HiUsing the administration portal, can an administrator see the password answers that a user submitted during Self Service registration? The reason is that we would like to incorporate the answers gathered in to our manual Helpdesk procedures so that if someone rings the Helpdesk for a password reset, for instance, then the helpdesk person can challenge the requester by asking them for the answers they submitted during registration. (As a backup to Self Service not being available or the user being incompetent!)Thanks in advanceS Dixon

You can't see the answers with the built-in password reset process. The answers are hashed on the client side (QAPlugin.dll ActiveX control), and then hashed again on the server side (QAAuthenticationGate workflow activity). In order to accomplish this, you'd have to write your own client-side ActiveX plugin and server-side AuthN gate workflow.Best of luck!Joe

In addition to the comments made by my esteemed colleague, Mr Zamora, I would like to point out that allowing the help desk to see the answers would be considered by many to be a security vulnerability, as anyone on the helpdesk could impersonate a user by using their questions to reset the password (that way it looks like the user did it).So I suggest that you use a different approach. For example you could add attributes to the user object that only the user, the helpdesk and the administrators can see and only the user and the administrators can set. You could develop your own client to prompt users to fill these in. Then when the helpdesk needs to reset the password they could use that to verbally authenticate the user.Otherwise you do need to "write your own client-side ActiveX plugin and server-side AuthN gate workflow."David Lundell www.ilmBestPractices.com

To reaffirm what the others have said, the questions and their answers essentially unlock the ability for a user to generate a new password, a.k.a. shared secret, therefore the questions and the answers are themselves now shared secrets. Therefore it is absolutely not recommended for you to even consider implementing your own AuthN activities that would enable other people access to this information, as it would be no different to storing a password in plain text in the helpdesk application. I suggest you re-evaluate your requirements or, should they be valid, which they seem like they could be, consider an alternative solution, e.g. a scoring system against private information known to both the helpdesk and an individual, i.e. an employee has a swipe card that lists their name and employee ID, therefore the employee ID should carry some weight, but should not be enough to verify ones identity to the helpdesk over the phone, so in addition you should provide your AD logon name and/or mail alias/address, date of birth, and a phone extension. You can argue that all of these pieces of information could be harvested by an attacker, and youd be right, however the likelihood is reduced down to pretty much only a valid request or a targeted attack. And youre already in this position arent you? You could take this a step further by implementing a password in the helpdesk system and the requirement to provide two or three characters of this password, selected randomly, e.g. you will be asked whats the second and penultimate characters in your password. This way the helpdesk dont actually know your password. Either way, ILM can only really help if you wish to utilise an identitys AD password, e.g. implement your helpdesk system as a connected data source and flow the password via PCNS.